To date, three different rights management methods have been defined and published by the Open Mobile Alliance. The three specified methods are known as “forward lock”, “combined delivery” and “separate delivery”:
With “forward lock”, the media element(s) is (are) packaged into a new data type which contains certain items of signaling information in addition to the media elements. Linked with the data type newly defined therein (“application/oma.drm.message”) is the restriction that the objects contained therein are not forwarded, not stored in the file system as freely accessible objects and may not be modified. Special handling of the objects of said type is therefore required by a terminal device.
With “combined delivery”, the media elements are packaged into the same data type as in the case of the “forward lock” method. However, also contained therein in addition is a rights description by means of which further restrictions in relation to the use of the digital media objects can be specified. Examples thereof are the restriction on the usage time, usage frequency or usage type (e.g. “do not print”).
With “separate delivery”, the media objects are packaged in encrypted form into a further newly defined data type (“application/oma.drm.content”), referred to in the following as a DRMC (“Digital Rights Management Container”), which in turn contains signaling information. The encryption enables the content to be protected against unauthorized use, even if it is handled by an application without specific DRM functionality and is stored in the freely accessible storage area of a terminal device. In addition, a rights object (RO) is transmitted to the recipient via a secure channel. In textual coding this is the data type known as “application/vnd.oma.drm.rights+xml”, and in binary coding the type known as “application/vnd.oma.drm.rights+wbxml”.
The rights object (RO) plays a central role in the two methods “combined delivery” and “separate delivery”. Said object contains the information concerning the rights linked to a content object (the rights description) and, when the “separate delivery” method is used, also the key for decrypting the encrypted content object in the DRMC.
The definition of the rights object is provided by the specification OMA-Download-DRMREL-v1—0-20020913-C in conjunction with an XML DTD (extensible Markup Language Document Type Definition) which can be downloaded from http://www.openmobilealliance.org/docs/drmrel10.dtd. Certain rights and constraints are contained in the current version of the definition for a rights object. The rights include:                “Play” (for audio-visual content),        “Display” (for visual content (images, video)),        “Execute” (for executable programs) and        “Print” (for producing a material copy of content such as e.g. images, texts or graphics).        
With the “separate delivery” method, the content object (the media object requiring protection) is contained in the DRMC. FIG. 1 shows a referencing of a content object from within a rights object in the “separate delivery” method. The DRMC has two components: on the one hand the encrypted content object (IO) and on the other hand a header part containing control information and a description of the content object. The control information includes a reference (“rights issuer”) to the rights provider (RA), which reference can be used by the terminal device to obtain further rights for the content object, and a unique reference, referred to as the “Content Uniform Resource Identifier” (CURI), which serves for referencing the content object from within the rights object (RO). Said reference (in the form of a URI) is used in the rights object as a reference for representing the connection between rights object and content object.
The separation of the content from the rights has conceptual advantages. As a result of the encryption of the content object in the DRMC, the content object can only be accessed by using the matching key. The DRMC is consequently rendered worthless as long as no matching key is available to an owner of the container. The DRMC can therefore be handled arbitrarily like another file. It can be copied and it is also possible and permitted to transfer or also to copy the DRMC from one terminal device (of user A) to another terminal device (of user B). This operation is referred to as “superdistribution”. The receiving user B of a DRMC can obtain access to the content object in the DRMC if he or she uses the reference to a resource of the rights provider (right issuer). A DRMC send operation can execute as follows:
The terminal device of the receiving user B receives a DRMC from the terminal device of user A. User B then decides to purchase matching rights for the content object contained in the DRMC. Next, user B accesses the rights provider resource which is encoded in the DRMC with the header field “rights issuer”. The rights provider thereupon offers user B a matching rights object for purchase. User B accepts the offer, buys a rights object and in the latter receives the key for decrypting the content object.
By means of this method an exchange of content objects between users is made possible, with the value added potential being preserved for the rights provider. The latter can charge a fee once again for the downloading of a rights object by user B, e.g. in an identical manner to the first downloading of a DRMC with associated rights object by user A.
It is in the interest of a provider of content objects here that a satisfied user A should recommend a downloaded content object to another user B and thereby create the basis for an additional sale of a matching rights object. In order to encourage the above described behavior of user A, which is desired by the provider of the content object, it is desirable to offer user A a bonus (premium) which the provider of the content object will grant user A upon a successful recommendation.
However, with the DRMC send operation described this is only possible to a limited extent in that a rights provider integrates into the DRMC a reference (header field “rights issuer”) that is uniquely assigned to the first receiving user A. A download operation subsequently initiated by user B using said reference for a rights object would allow the rights provider to trace back the recommendation to user A. The described operation does, however, have the disadvantage that a DRMC cannot be assigned dynamically to different users and premiums. Multiple forwarding by different users, each having a new and individual premium description and concession, is therefore not possible.